Anyone who has bought a personal computer or laptop for their home, office or school work can appreciate the meaning of planned obsolescence. Software developers are constantly adding new features requiring faster and more powerful hardware to run on, and hardware makers oblige by constantly improving the performance of the computer chips used to make personal computers. Sometimes it seems to the consumer as if there is a conspiracy going on that requires you to “upgrade” (i.e., replace) your entire personal computer set-up every two or three years or so.
The constant changes and improvements in computing equipment software means that better systems with improved performance and capabilities are always being developed. Many of these new systems are entirely incompatible with older computing equipment and software, and will not inter-operate with them. This creates a significant problem for established businesses and organizations who want to continue using and receive value from the significant investment they have made in older computing systems and applications while nevertheless obtaining benefits of newer technology.
Despite the constant flurry of new software and hardware, the Y2K issue showed us all that some of the world's most important computer-driven process infrastructures are actually relatively old. Computer infrastructures that seem to have remarkable persistence are the numerous database and other specialized applications that long-established businesses, governments and other organizations rely on every day for crucial information.
Once a business or other entity has made the significant investment of purchasing or developing a specialized software application for one computing platform and then using it to input significant amount of data to build up a database, it is often very difficult (and may be extraordinarily expensive) for the business or other entity to change to another application on a different computing platform. The investment goes far beyond the computer equipment itself—the often hundreds or thousands of person-hours involved in inputting the data cannot be instantly duplicated. The investment becomes significantly more substantial if the software application was custom-developed since it is rarely straightforward to simply transfer or duplicate the functionality with another computing platform and associated application.
For example, beginning in about the 1960's and continuing through the early to mid 1990's, most businesses and other organizations generally relied on larger computers known as main frames or mini-computers (which were still relatively large) for their most critical computing needs. Companies such as IBM, Digital Equipment Corp. and Wang supplied the world with such larger computers and associated software, and business. Such computing systems generally included centralized larger computers—sometimes as big as an entire room. Users accessed such computers via so-called “dumb” terminals consisting of a display, a keyboard and a communications device but no real processing capabilities. Users would use the “dumb” terminals to input requests. The host computers would respond by sending the terminals display screens containing the requested data. Countless specialized applications such as accounting, database management, billing, inventory control, and all sorts of other functions were developed for these host computers. Many of these applications continue to be used today—despite the advent of the personal computer and the World Wide Web.
When computers-on-a-chip (microprocessors) were invented in the mid-1970s, people began building much smaller, “personal” computers. However, it was not until the late 1980's to early 1990's that businesses began widespread adoption of personal computer-based client-server networks instead of the larger host computers. Fueled by the Internet and the World Wide Web, personal computer (or smaller computing device) networks configured in distributed client-server fashion are now generally the computer infrastructure of choice for most businesses and other organizations. Even though the client-server architecture is now the platform of choice, many businesses and other organizations continue to maintain and rely on older, mainframe and minicomputer based systems for certain critical data—not necessarily because they prefer the older technology, but rather because the older technology continues to work (“if it's not broken, don't fix it”) and it is often difficult and cost-prohibitive to migrate data and/or applications from the older “host” computing to newer client-server topologies.
Data that resides in the older, host applications can be very difficult to access by the newer, personal computer network (e.g., client/server) based technologies. The underlying storage format used in the older (or even newer) host-based applications often makes the use of a dumb terminal (or a terminal application emulating one) mandatory for retrieve or change. Prior approaches to this problem usually involved client programs, in conjunction with terminal emulation software, to “scrape” data from predefined locations on predefined screens supplied by the host application. In other words, such client programs would use terminal emulation software to retrieve data from the host application by making it appear to the host application as if it was being accessed by a conventional, older-styled dumb terminal capable of data input, display and not much more (when in fact the access was being performed by a personal computer or a server executing emulation software that made it appear to be a terminal). The resulting data screen formats the host application generated for display would then be “scraped” to harvest the needed data from predefined locations on predefined screens within this display information.
This prior approach provided some degree of interoperability but was no panacea. One problem that remained was that there was little or no abstraction from the terminal screen to the client programming applications programming interface (API). This meant that the newer-technology (e.g., personal computer based) client had to be programmed very specifically for the particular host application being accessed—forcing a one of a kind, custom client solution that was relatively expensive to develop and required a significant amount of expertise to develop and put into place.
In September 1999, WRQ, Inc. released a product called APPTRIEVE (also known as Veristream Host Integrator 3.5) that took a significant step toward the goal of abstraction by exposing host data screens as objects. WRQ's APPTRIEVE software was intended to provide an application mining solution that enables organizations to quickly and easily build e-business applications that integrate legacy data from IBM mainframe, AS/400, VAX and UNIX host systems. APPTRIEVE gives web application developers with no expertise in host systems easy, object-based access to legacy business logic without requiring any custom programming, or alterations to the host system. Generally, such APPTRIEVE software provides a graphical legacy application mapping tool, a development kit, and a powerful server that graphically maps the legacy application, builds a new application and deploys the new application. With a simple point-and-click interface, APPTRIEVE provided an ability to create a graphical map of desired legacy data and then make it accessible via a Java Bean or COM object.
The APPTRIEVE/VERASTREAM server technology could be regarded as an “integration broker”, i.e., a type of middleware that straddles diverse systems and technologies to unite dissimilar data sources. Before integration brokers, teams of programmers had to build point-to-point connections between systems on a case-by-case basis. Every new system that was added to the configuration required additional custom coding. What's more, maintaining those connections each time a new feature was added or an application was upgraded weighed heavily on IT budgets. The integration broker overcomes these limitations by virtue of its hub-and-spoke configuration. It serves as the hub, so adding a new system means connecting it directly to the integration broker. Then, all existing systems, which are already linked to the integration broker, can instantly interact with the new system. Running in cooperation with application servers (such as IBM WebSphere, BEA WebLogic, or Sun iPlanet), integration brokers allow companies to integrate legacy data and applications with new components developed in C/C++, Java, or Visual Basic®. Integration brokers can also expose legacy applications as EJB (Enterprise Java Beans), CORBA, or DCOM components.
While WRQ's APPTRIEVE/VERASTREAM solution was successful in allowing the client to interoperate with the host application by making the host application data appear to be a data object to the client for access using standard database formats, the client API still required a programmer to understand the structure of the host application. Most client API programmers, such as web developers, have little or no experience with the host applications and do not really care to learn the older software. Moreover, since requests were made on a per-screen basis, many network roundtrips between the client and the APPTRIEVE server were necessary for even the most basic access. Accordingly, further improvements were necessary and desirable.
The present invention provides such further improvements by encapsulating the host application so it can be abstracted and accessed by industry standard query languages such as the Standard Query Language (SQL). By encapsulating the structure of the host application, clients can retrieve or change data on the host without knowledge of how the host application functions. Since the data requests can be made via such standard access techniques, most kinds of data access can be accomplished in a single network roundtrip between client and server.
In accordance with an aspect provided by preferred illustrative embodiments of this invention, techniques are provided for abstracting the details of an application (e.g., including but not limited to an application running on a Legacy host computer and intended to be accessed via terminals) so that data from the application can be efficiently accessed and provided to otherwise incompatible equipment and software (e.g., a modern personal-computer or other based client using the SQL or other industry standard protocols and conventions).
In accordance with another aspect provided by an illustrative and preferred exemplary embodiment of the invention, a method of abstracting a host application so it can be accessed efficiently from a requester that is substantially non-interoperative with the host application involves establishing a model of said host application; resolving requests from said requester into at least one procedure; executing said at least one procedure in conjunction with said model in response to a request from said requestor to generate at least one host request and to elicit at least one host response, said executing step including at least one of: providing at least one input parameter obtained from said request to said host application, and providing at least one data item elicited from said host application to said requester.
In accordance with one aspect provided by an illustrative and preferred embodiment, standard database access requests from a requestor are parsed and resolved into one or more access procedures. These access procedures are executed (e.g., each in turn) to send requests to an application and to receive responses and extract relevant information from those responses. The extracted information can be optionally filtered before being returned to the requester.
In accordance with another aspect of an exemplary and illustrative embodiment, the request is structured as an industry-standard (SQL or other relational) database requests. Such requests are parsed to extract parameters, and are then mapped into a set of predefined procedures that are created to generate application-specific requests that elicit desired responses (e.g., call up a certain input screen in the host application, fill in certain fields within the input screen with certain parameters, send an enter or other command to the host application that requests the host to process the inputted parameters and provide a response screen, extract desired data from predefined locations within a host-provided response screen, and provide the extracted data to the requester).
The accessing techniques provided in accordance with the preferred exemplary embodiments of this invention allow the client or other requester to be completely insulated from the details of the host application. The client or other requester can communicate its request in an industry standard or other language, and the request will be interpreted and translated automatically into an appropriate set of requests to the host application in the requesting language or other protocol that the host application understands. Similarly, host responses once received will be analyzed automatically and appropriate information extracted from them and provided to the requester in the requester's own language. Advantages include allowing businesses and other organizations to continue to efficiently make use of legacy and otherwise-incompatible applications while allowing users to embrace and more fully utilize newer, often more powerful and versatile technologies such as client-server based computing system. Furthermore, the ability to use otherwise incompatible (e.g., industry standard) database interfaces can dramatically reduce the size, complexity and cost of developing new interfaces. For example, such encapsulation may prove to be important in integrating with many third party tools. Additionally, the user of database drivers (e.g., JDBC) can enhance functionality for business partner tools that already use industry standard interfaces to access “backend” systems such as relational databases.